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NEWSLETTER DEADLINE 

Deadline for ready-to-use material for the next Newsletter is October 29- 
Material requiring editing /re-typing must be In earlier. Note: a review 
of material in recent Newsletters will show what sort of submissions re- 
produce well and what do not. 

SIG BUSINESS 

To date no formal response has been received to our request to the DECUS /US 
Executive Board for representation of our 12 Bit Special Interest Group on 
the Board. The request was presented in May. Informal communications in- 
dicate that the Board intends to delay any action on the application at 
least until the December meeting in Las Vegas, So far no further word is 
available on the subject. I expect that we will discuss ?.t in the SIG 
meeting at the Symposium in December. In any case we need interested 
members with ideas and energy to contribute to the activities of our 
Special Interest Group. In particular work on the Symposium and contribu- 
tions to the Symposium are needed, and we would like to build up local user 
groups and hopefully regional get-togethers of 12 Bit users on a compara- 
tively Informal, low-cost basis for exchange of ideas and trading help 
and maybe even actually writing programs that are needed by the user com- 
munity. We also need inputs on other new and creative ideas for SIG 
activities. 
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FALL DECUS SYMPOSIUM 

The schedule for the Fall Symposium to be held the week of December 6 at 
the MGM Grand Hotel in Las Vegas has "been set. It contains an interesting 
and more extensive program for 12 Bit users than we have had the last few 
meetings There will be the usual Product Panel for the PDP-8. We will 
have a business meeting for the Special Interest Group where several im- 
portant matters will be discussed and inputs from users will be solicited, 
and there will be a workshop on OS/8 topics all scheduled for the first 
day. Notice that the first day is Monday this time. The symposium is 
running from Monday through Thursday rather than the normal Tuesday 
through Friday. On the second day there are plans for workshops on the 
FPP-8a floating point processor, on MACEEL and its LINKER and on RTS-8. 
Also on Tuesday there will be a DECnet-8 session. On Wednesday afternoon 
there is a session of OS/8 application papers. Also scattered throughout 
the program are other items of interest to the 12 Bit community and al- 
though the program schedule is quite tight we are planning to leave pro- 
visions in the scheduling to try to fit in late developing material. One 
of the ways that we will be handling this is through birds-of-a-feather 
sessions which can be set up almost on the spot. 

Due to the incredible backlog that has developed in PDP-6 products lately 
no one knows what hardware DEC will be able to send to the meeting yet. 

PH. DOBB'S 

I heard recently from Jim Warren of the People's Computer Company in Menlo 
Park, California, who is the editor of Dr. Dobb's Journal of Computer Calis- 
thenics and Orthodontia ("A reference journal for users of home computers"). 
As many of you already know, "Dr. Debt's" is a very interesting member of 
the growing community of publications aimed at micro-computer users, and in 
particular the "personal computing" segment. It concentrates more on the 
software side than some of the other publications such as BYTE. Jim wrote 
to me because he has his own PDP-8 and is interested in OS/8. I suspect 
that the personal computer world will soon start to discover OS/8 and the 
other PDP-8 software, first because it makes an excellent design model 
for a small, flexible operating system for any of the micro-computers but 
also because micro-computer class versions of the PDP-8 are now emerging 
and OS/8 will be the best software available for the more complete systems 
(i.e., ones with at least 8K and a floppy disk). 

FOLLOW-UP ON DIRECT /A 

Larry Fowler from Boeing wrote to remind me that the directory alphabetize 
work was originally his and it was distributed at the Fall 1975 DECUS Con- 
ference. You will recall that in a previous Newsletter I mentioned that 
his name had been lost in the scramble. Since mentioning in the previous 
Newsletter that a version of DIRECT with the /A option was available from 
me I have heard from Tom Mclntyre that he now has available a further im- 
proved version which implements the alphabetize feature, a feature for 
printing DECsystem-8 labels and volume numbers if they are available, and 
a feature that I like very much of printing multiple column directories 
ordered vertically rather than horizontally which makes them much easier to 
use, I think. Because Tom's version is substantially superior to the pre- 
vious ones, including mine, I am withdrawing my version in favor of Tom's 
which he has promised to submit to the DECUS Library " ,r ery soon. In the 
meantime you should contact Tom if you have any questions regarding it. He 
is at the Department of Physiology and Biophysics at West Virginia University 
Medical Center in Morgantown, West Virginia 26506. 
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NOTES FROM JIM YAH ZEE 

Jim has been in a flurry of activity in preparation for finishing up work 
at the University of Washington. In particular he has been adding even 
more features to U/tf FOCAL and trying to make it into a good "final" form. 
It's hard for me to keep up with all of the enhancements that Jim keeps 
inventing. Among the latest is a function to access the OS/8 system date. 
He has added more "secret variables" and he now can once again support 
a 6 digit version of FOCAL although he still believes that the 10 dig! r 
version is by far the preferable version. Jim also has a way passed on to 
him dj Steve Gillette of the U.S. Geological Survey in Flagstaff to add an 
"empties" option to the List commands so FOCAL can now print a complete 
map of a directory including empties with only the file dates missing. 
He also has invented an Open Second command for the 12 and l6K versions 
and, of course, an Open Restore Second command. This means that you can 
have two open files simultaneously. So now you can have two OS/8 files 
plus the terminal going at one time. Jim has had a series of corrections 
and improvements to his VC8S handler. The DSCUS Library and I are sorting 
out the latest versions of it. It should be all taken care of and into the 
Library long before you receive this Newsletter. Jim has written a program 
to use many of the special functions of FOGAL to aid in reconstructing a 
crashed directory using aPIP/E listing of it. Similar things have been 
done before such as Tim Clark's version in TECO but this is a rather in- 
teresting demonstration of the capabilities of U/W FOCAL. 

Sncl«-;t.cJ. ;=lst:wiie.re is an SPR from jim regarding a problem that he ran into 
recently when he discovered that the latest release of PAL8 (Version 10) 
seems to have shrunk the symbol table rather substantially. People with 
large memory systems don't really know the difference, in fact, you don't 
have to use /K any more to use extended memory for your symbol table so you 
don't even know that this change has taken place, but if you have an &K 
system that just barely assembled something like FOCAL before because of 
the limitation on the number of symbols you are now out of luck, apparently. 
Does anyone else have any input on this subject? In the meantime, I sug- 
gest that you be sure not to throw away your last copy of the old Version 9 
if you have any possible need for the larger capacity. 



MATERIAL FROM LABS PALMER 

Lars has sent along a couple of paper tapes that incorporate: 

1. The /M patch to 0S/8 FORTRAN IV PASS3 that was mentioned in a previous 
Newsletter. 

2. Several patches for FRTS: 

a. The input error patch as submitted by Jim Crapuchettes . 

b. The patches to FRTS for the USR subroutines by Bob Phelps. 

c. The patched FRTS allowing it to pick up command decoder switches. 
A subroutine using this patch will be submitted to DECUS soon. 

d. The core allocation patch to use BAT with FORTRAN IV. 
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NOTE FROM TIM CLARK 

Tim has sent along word on a number of interesting developments. First, 
he has written and documented a TECO macro that will strip out comments 
from any TECO macro thus compressing it. This would he a very useful tool 
for everyone to use when they are writing complicated TECO macros as It 
allows them to fully document the macro but still conserve space at run 
time. The use of something like this seems almost mandatory if we are ever 
to establish a library of TECO macros for general exchange. 

Tim also enclosed some information on a FXDIR technique for fixing direc- 
tories using TECO and other OS/8 programs. 

Tim reports on Jim Crapuchettes , latest work on FUTIL which will make 
several new features available. Final plans aren't set yet but he is 
trying to at least include support for FORTRAN IV load modules, the FP? 
instruction decoding, a BYTE mode for output and a WRITE with block num- 
ber argument. 

Other things of interest that Tim has done recently include: 

1. Adding an instruction to OS/ 8 TECO that provides memory examine and 
deposit functions. This is useful for turning on and off echo and 
zero suppression and releasing space for two-page handlers. Of course, 
it has potential for causing no end of grief as he says. 

2. TECO macro that, given an ASCII DIRECT file or any suitable list of 
file names, will generate a batch input file that will OCOMP on all 
the specified files on two devices. This is useful for comparing the 
results of a SQUASH transfer; for example, because OCOMP does an octal 
comparison between the files. 

3. He has also worked up a set-up to allow the MR8E (TD8E ROM bootstrap) 
to boot either the TD8E system or another (typically a disk) system. 

k. Finally, Tim is looking for a report on success with writing LINCtapes 
on a TD8E. He suggests someone with experience should write It up for 
the Newsletter. 

Tim says that anyone wanting copies of CMPRS and FXDIR can send him two DEC- 
tapes or LINCtapes or floppy disks and he will send one of them back with 
the appropriate material on it . His address is : Frelan Associates , 
PO Box 298, Menlo Park, CA 9 } *025. 



NOTE FROM AREND KUMAP 

Mr. Kumap writes to note that the available patch for TIME problems of 
FORTRAN IV does not work correctly. No further information was included. 
He notes that FLAP and the FPP support library are still available from 
DEC, they work, and he indicates that he is interested in learning more 
about RTS-8 and FPP- 12 programs. He is ready to cooperate with others on 
the subject. He has a l6K PDP8/E with FPP- 12 and RK05. His address is': 
Universiteit van Amsterdam, Laboratorium voor Psychofysiologie, Eerste 
Constantijn Huygensstraat 20, Amsterdam, The Netherlands. 
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NOTE FROM CHARLES RAY SMITH 

Ray sent along information on something he ealls PSD. It is a PS/8-OS/8 
symbolic de-bugger. This is rather like the DDT that is available with 
the kK Disk Monitor. That is, in addition to the features of OBT which 
accesses core strictly on an octal basis this package can accept the symbol 
table output from PAL8 using the /D option and then during your de-bugging 
it's possible to reference locations by their symbolic name, unlike the hK 
Disk Monitor DDT, however, PSD Is core resident and you have to allow space 
for It. It is based on XDDT (DECUS 8-127) with the addition of OS/8 facili- 
ties . 

Ray notes that he has had some difficulty with the OS/8 FORTRAN II/SABR 
package with respect to formatted I/O which he has been trying to implement 
for the CALCOMP plotter. He Is trying to arrange it so that the CALCOMP 
replaces the high speed punch as device #2 for formatted output. He would 
like to see more convenient "hooks" into the format conversions for user 
written routines. He would like to have an arrangement where a user 
written module is called on a character by character basis for Sbn-DEC 
supported device numbers. He has also found a problem In IOH. It seems 
that during E format output there is a call to the DIV routine, then there 
is a call to the PRIST routine and then there is a cctff to the IREM routine 
to fetch the remainder of the last DIV call. In the nomal DEC I/O routines 
this proves to be no problem because the I/O routines do not call DIV 
themselves so its status is preserved, however, in his case his CALCOMP 
symbol plotting routine is using the DIV routine for scaling purposes. 
Anyone else trying to write their own special formatted I/O routines could 
run into the same difficulty. He suggests either storing both exponent 
digits before outputting either which means a modification to IOH. SB or 
else to modify IOH. SB to branch to a routine called USRIO instead of GENIO 
when the device read or write number is greater than h. If you are interested 
in contacting Ray he is at MIT Laboratory for Nuclear Science, Cambridge, MA. 
02139 - Room 2U-00U. 

NOTE FROM H.S. HOPKINS 

Mr. Hopkins has made several recent submissions to the DECUS Library. The 
first is ALPHA which is a versatile sorting program enabling the listing 
of OS/8 file directories on any of the h fields; file name, extension, 
creation, date and/or starting block number. He would eventually like to 
be able to integrate this entire facility into DIRECT but at the moment he 
doesn't have sources to make that possible. At the moment it's a stand 
alone program. He has also submitted a version of CCL that implements an 
ALPHA command that works the way a DIRECTORY command would, only it calls 
his program instead. He has also submitted a version of MARK12 to make 
it more useful for both DIAL and OS/12. He also has worked up a one-word 
patch to DIAL to make it work with the LS8F Centronics printer, and possibly 
the DECwriter lis on PDF- 12* s. He submitted an SPR on the problem and DEC's 
response eventually was that they would not make the fix generally available 
so he ha*.- included the information in his submission to DECUS. He says in 
anticipation of the delays in getting the programs into the DECUS catalog 
if anyone needs them he will be happy to be contacted directly. He doesn't 
have high speed reader and punch so he would prefer to deal either with 
DECtape or LINCtaps for the OS/8 programs and in LINCtape for the PDP-12 
programs. He also has a number of things that he has done with DIAL that 
are yet to be submitted to DECUS which DIAL users may find of interest. 
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NOTE FROM DAVID MILLER 

David suggests a couple of names under our Name-the-SIG project. The 12 
Bit SIG might be called BUG BYTES or DE-BUG BYTES. .Any more ideas out 
there or any thoughts on the subject? 



NOTE FROM BRIAS CONVERSE 

Brian writes to note that in the latest release of OS/8 (OS/12) that he 
received, h of the 8 LINCtape handlers have disappeared from the non- 
system device LINCtape handler. I have come across that complaint from 
others also. Does anyone have any information on this question? 

NOTE FROM STUART DOLE 

Stuart tried the patch to OS/8 BASIC submitted by T. Wes Sikes and dis- 
covered that it had problems with long programs on machines larger than 
8k. He has sent along a revised patch which fixes the problem and also fixes 
an "EN" error bug. 

NOTE FROM L. E. BYRD 

Mr. Byrd notes that with his LA30 printer the previously published patch 
for DIRECT that- ch«"se« the def»«~5t number of eoliHRns in a listing to 
three would not work because three columns were still too wide for his 
printer. He suggests changing location 12307 from 7125 to 7126 to change 
the default number of columns to two which he says is quite satisfactory. 



PROBLEM USING VT5Q TERMINALS 

Two people have written with problems that they are having with the VT50 
terminal. Both problems are due to the fact that the VT50 seems to send 
7 bit ASCII with the 8th bit set to zero rather than the traditional conven- 
tion on PDP-8's of setting the 8th bit to a one. Some software apparently 
still doesn't know enough to force the 8th bit on or otherwise deal with 
the problem. First, Rudi Stange from DEC Sales Support In Munich has noted 
that DEC'S RK05 disk formatter program (DHRK0-A) will not work on a DEC Data 
System 310 which uses a VT50 as its terminal. This Is because it does not 
handle the 8th bit correctly so It can't accept inputs to the quest ic is 
that set it up. Therefore, on the system he is working with he cannot for- 
mat disks. He has sent along a suggestion on how he patched software to 
make it work. If anyone Is Interested let me know. Also on the same 
problem Jim Van Zee notes that the PARAM program in DECsystem-8 has the 
same problem. He used FUFIL to search through the program for all the 
occurrences of test constants and he added 200 to them. This should be 
fair warning to anyone writing software for the 8 that It had better be 
able to deal with either convention for the 8th bit for the foreseeable 
future if they want it to be portable from one configuration to another. 
The most common way to do that is simply to mask each input character with 
a 177 and then add 200 thus forcing the 8th bit on in the input driver. 
Then the conventional PDP-8 coding using the 8th bit set will work in the 
rest of the program. 
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NOTE FROM ANGUS FERGUSON 

Mr. Ferguson sent along a modification to FOTP, some comments on LIBSET 
and also a version of LIBSET that lie has been working on. First, he finds 
that the /Q option in FOTP is annoying with a LA36 DSCwriter due to the 
fact that the last character of the file name extension is hidden by the 
printer head before it moves aside after printing the file name and 
question mark. This slows down the use of that option. The following 
patch is suggested to add an extra question mark to pad out the position of 
the head 

. GET SYS FOTP 

. onr 

14233/4770 4337 

14337/xxxx 0; 4770; 1371; 4770; 5737 

tc 

.SAVE SYS FOTP 

Notes on LIBSET. The documentation in the OS/8 software support manual 
pages A7 and 8 for the structure of the FORTRAN II library files is in part 
incorrect according to .Angus. The main error is that each entry point is 
allocated only one loader control word {LCtf) which is always followed by a 
zero (not two LCW's as is shown on page A8) thus a .RL file with 3 entry 
points will have 3 entries of the entry point names and load pointers 
(3x4 word) in the directory and cnly one LCW no natter how long the file 
is (less than 37 pa?:es, of course!}. Another error concerns the use of the 
/S option as described in the OS/8 handbook (page 4-69) . The option 
*</fe works correctly for the first line (LIB8.RL default output file), 
however *LIB8.RL <fs returns immediately to the command decoder. 

The example on page 4-70 of 

*ASIN,AC0S 
*/S 

also returns immediately to the c-maand decoder after the carriage return 
on the second line. He says the reason is perfectly obvious if one examines 
the source. A simple patch of 126 16/5244 5225 will fix first bug but a 
source change is- required or a large patch to correct the second bug. 

Angus has modified LIBSET considerably, now calling it LIBFII, to do the 
following: 

a. Accept a library file as input on any command decoder line by using the 
/L option. This provides a method of listing existing library files. 

b. All entry points in the new library are listed at the termination of 
the program. 

c. Corrects the above problem in LIBSET. 

He plans to submit LIBFII to DECUS. However, if anyone would like a binary 
copy of it in the meantime they can write to him. The address is: School 
of Earth Sciences /Drpt. of Geology, University of Melbourne, Parkville 
Victoria, Australia 3052. 

He has also forwarded a copy of LIBFII on paper tape to me. 
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If you like to bomb directories, (or even if you don't like "to, but do,) 
there are several techniques of directory restoration available. First, though, 
a few comments on how directories get lost. 

1. The post straight forward method is to use PIP and do *DEV:</7. 
inadvertantly. Of course, you realize that to zero a directorv reouires only 
three (3) words to be changed in block 1. Thus an inadvertant zeroing of a 
device by PIP could be undone by a 3 word natch with FUTIL. But this was too 
simple for PIP. It thinks it has to write all 6 blocks with what amounts 

to gibberish, thus removing any chance of restoring the original directory. 
WHY ?? 

2. Similar to the technioue above is the CCL technioue of .ZERO DEV:. 

CCL then invokes the method above for zeroing the device. The original release 
of CCL (version 5) did not check for a colon, so if one did a .ZERO DEV without 
the colon, CCL obliginoly decided that you wished to zero the default device. 
So, slain, bain, thank you, there went device DSK:, (which is often SYS:), even if 
you only wanted to initialize a freshly formatted taoe or disk. CCL is s<r»art 
enough to reject any specification with a filename, (which would be the case if 
the colon were inadvertantly oss-nitted, ) as a filename with or without a device 
specified is irrelevant in a ZERO operation. A modification to CCL to orcvide 
this check was published in DIGITAL SOFTWARE t?EWS of 1974 August. Do it! 

3. FOTP or DELETE with *.*/D will leave you with one EMPTY for each 
directory block used. You get what you asked for, using the •netho-d you asked 
for. The method of deleting all files one by one is not amenable, and need 
not be, to 'second thought 1 , or failsafe operation. 

4. Directorv problems can be caused by an i/o problen with the device 
or raedia (disk or tape), e.g. checksum error, rnaking a directory olock 
unreadable by the OS/8 device handler. A cuick solution that sonetires works 
in this situation, (especially with LIriCtapes with the TU55-TU56 skew orobler.) , 
is to read the bad block with FUTIL. With most devices the block has been 
transferee! into the memory buffer before a checksum error is detected and the 
device handler takes the error return. If so, FUTIL will give notice of a 
read error, but the contents of the block ore in FUTIL* s buffer. Check it 
out. Sometimes there are no errors, sometimes one or two to be Patched with 
FUTIL. In any case, a FUTIL WP.ITE operation after the REAO will often fix the 
checksum problem. 



DIRECTORY IIESTOPATIO'3 : If the directory is not up to date, or needs 

modification, aoprcoriate changes must be made with each technioue. Finding 

lost files requires some detective work - qenerally with the aid of FUTIL 
or 5TEC0. 

1. If you have a nrogram that saves a copy of the 6 directory blocks in a 
safe place, it should have a restore node. Use it, and you're home free. 

2. If you have a copy of the directory on paper only, then you have the 
choice of using FUTIL to generate the whole directory, or zeroing the directory 
and using PIP with the DEV:narco</I=n construction. Roth of these techniauec 
are tedious and prone to errors, particularly if one wishes to preserve the file 
dotes. 
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3. If there is no copy of the directory preserved, either on paoer 

or in a file, there is little choice but to use STECO for the ASCII files, 
(see OS/8 Handbook), and FOTIL for the rest, 

4. The FIXDIR protocol has the following salient features : 

1. Most of it is done with ASCII files, so it is versatile and 

easilv tnodified. 

2. Itf uses only CUSPs. (FUTIL is a CUSP.) 

USING FIXDIPv : 

The FIXOIR protocol uses a DIRECT /E/B output file for directory backup. 
Of course, this file should be saved on a device other than that for which it is 
a directory. The DIRECT /E/B output file (Device. DI) , is an ASCII file, so it 
may be readily examined by editors or listers. Any neccessary modifications n*ay 
be inade with an editor. An additional benefit of using ASCII files is that 
SRCCOM may be used to compare the backup DIPECT file with a DIRECT file froii the 
final restored directory. 

STEPS IN USING FXDIR : 

1. Locate the backup file and edit it to look like the desired directory for 
the device. 

2. Run TECO, load FXDIR. TE, setup input and output files, execute FXIDIR. 
EXAMPLE: 

.RUE DEVrTECO 

*ERDEV: FXDIR. TESYHXDERDEVl:DEV2.DI$EWDEVl:DEV2.PASMDEX 

3. Pieyate the target directory area to look like the following : 

.R FUTIL 

OPTION DEVICE DEV 

LIST OCTAL 1.2-6 

0031.00600: 7777 0008 0006 0S00 7777 0000 7777 

LI OC 2.0-6 

0002.00000: 7777 0003 0006 0003 7777 0000 7777 

LI OC 3.0-6 

0063.00000: 7777 0000 0005 0000 7777 0000 7777 

LI OC 4.0-6 

0004.00000: 7777 0000 0006 0000 7777 0000 7777 

LI OC 5.0-6 

0005.00000: 7777 0000 0006 0000 7777 0000 7777 

LI OC 6.0-6 

0006.00000: 7777 0000 0000 0000 7777 0000 7771 

~C 
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.DIRECTORY DEV:/E/B 

31-DEC-79 

<EMPTY> 0008 1 

<EMPTY> 6008 1 

<EMPTY> 0000 1 

<£MPTY> 0000 1 

<EKPTY> 0090 1 

<EHPTY> 3090 7 

12 FREE BLOCKS 



4. Assemble the file produced by FXDIR. DON'T FORGET TO USE /F! 
Restore the directory by saving the file on the device. 

.R PAL8 

*DEV/F/L$ 

.SAVE DEV:DDHMY 

If you wish, you xaay save the file and then load it th igh PI? 

.SAVE DV:DEV 

.R PIP 

*DE V : DUMMY<DEV . S V/I 

5. Compare the resultant directory with desired results. 

.DIR TM<BEV:/E/B 
.COMPARE DEV.DI # T«M.DI 

No Differences! 



The following should be obvious to the most casual observer : 

1. The preceding setup will overwrite the bootstrap block, (block 0) , and will 
restore only 5 of the 6 directory blocks. The boots trao may be restored bv 
using PIP /Y. If you have enouqh files to use 6 directory blocks, "the ^receding 
scheme can obviously be extended to use block 7. 

2. If your directory backup file is not /E/B, you must fix it un to look like 
one or merely make the obvious changes required in FXDIR. TE. 



• CMPRS.TP 76.02.05 !! 
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TECO MACRO COMPRESSOR : 

The importance of the comment field of a program increases *s the 
program becomes more complex. This is perhaps especially true for TECO 
programs (nacros) , which are very compact statements & tend to read as 
hierogliphics anyway. While many languages have assemblers or compilers 
which, in effect, strip off the comments, TECO, being an interpreter, 
keeps them as part of the program, thereby occupying some of the space, 
{which is so often minimal), and slowing execution, (as the comment 
fields ''till must be scanned). 

Comments in TECO are also labels, so, even if it were possible 
to strip off the comment fields by syntactical analysis, labels 
also would be deleted and the program rendered non-functional. 

CMPRS is a TECO macro that defines all comments that incl <de a 
CRLF to be comments, (and therefore expendable) , and all which do not 
contain a CRLF to be labels (which therefore must be kept). 
Thus CMPRS deletes from the macro ail comments which include 
a CRLF, and deletes the following CRLF if there is one. 

Since a complete syntactical context check is not done, any 
literal text fields which contain an exclaimation point must ' 
observe even parity within the line of code. See CMPRS itself 
for examples of methods of doing this! ! Of course CMPRS 
can compress itself - (with this many comments, it'd better be able to) ! 

i 

Start at the beginning & find the 1st label or comment 

(include a dummy exclaimation point for parity.) 

The search also provides the means of exit from the loop 

i 

3 < S£ c ""*!< z 

I 

Back off to just before the exclaimation point 

If find end of label before find CR, do the whole thing over 

-1C 0UA < %AA-~~«"E QA+1C "~!S OAGAIN$ 

If the next char is CR, then 
i 

* QAA-13"N > 
i 

Delete all chars from the begining of the comment to the current location 

then delete all chars until find end of comment 
i 

' 0A+2D <8A-"~!"N D !$ > 
i 

If a CRLF immediately follows the comment, delete the CRLF also 
i 

' ID 8A-13-E lA-~~ 

"E 2D 

Do the whole operation until no more label/comment fields are found, 

then tell'm it's compressed 

! 

" IAGAIN! > ZJI 

!COHPRESSED!$ 

j 

And that's all there is to it! 
! 



A postscript on conventions: I like to use the extension .TP 

(TECO Program) for the commented files, then the standard .TE is used 

for the compressed versions. 

TIM CLARKE 

FKELAN ASSOCIATES 

BOX 298 

MENLO PARK, CALIFORNIA 94025 
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[his b- Ac rWt.of CMFSS.TP beiWj ^otdk f <A hyCWJtS- 
fe $ie macro itse/f £ «o <&w»**k 



! CMPRS.TP 76.02.05 ! 

J < S!$ ~~!$ 
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ITEMS FROM LARS PALMER 

3STOS Users 

As an user of the ETOS Time Sharing System in an environment slightly different from 
that which it was intended (the educational market) , I would be very interested in getting 
contact with anybody that runs ETOS under similar conditions. We will probably find 
that we have several things of interest together and that we could share a good deal of 
experience of the ETOS usage. Anybody interested in such a swap of ideas please send 
your name and address to me together with a short list of what you can contribute to the 
ETOS environment. Myself, I have the following material available: 

1) TRUE patches for several of the OS/6 V3C programs to run them under ETOS. 
These patches are TRUE overlays, i.e. they do not reorganize core the way 
ETOS source patches do and it is therefore possible to use the patching mechanisms 
supplied by DEC for farther patching in the programs. I have patches for most of 
the cusps, for FORTRAN IV System and for the OS/8 BASIC System except for the 
Editor which we do not use. 

2) I have subroutines available which makes it possible for a FORTRAN IV program 
to determine whether it runs under ETOS or not, 

3) We have added to the TIME program a new option , /A (account) which will give the 
account and console number of the specified job. This makes it possible to obtain 
this information from an non-privileged users job. As I understand SYSTAT will 
not be privileged in next version of ETOS but until then this is a good way around 
it. 
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Concerning the IOT codes on PDP-8 1 have run up against another one of DEC's 13 

internal communication problems. All documentation to PDP-8 says that 
"FPP 12 has device code 55 (and 56) and AD converter device code 53". This 
is so in all new configurations and all DEC software including MAINDECs are 
assembled with these codes. 

We received a new PDP-8A Lab machine and decided to test it with FORTRAN IV 
before installing the AD8A whicL was placed in the bus as per delivery. Everything 
crashed. This was repeated every time we ran FORTRAN but all MAINDECs (except 
the AD converter which was not yet tested) ran perfectly. On a thorough digging into 
the documentations to the machine, we found a sentence saying "The AD8A is delivered 
with the device code 55 installed" (the AD8A like the KL8E has switch selectable device 
codes so fixing the problem was trivial once the problem was diagnosed). 

When doing sampling from ADC to disk there exists a need for fast routines. 
Many attempts have been made to achieve a better result than the standard 
REALTM WRITE (n) eombiii&tion. I have just completed one routine WRITBL/READBL 
which I have sent to Bob Hassinger. The following information might be interesting. 

I have tested several routines for thruput speed. The configuration used is PDP-8E + 
RK8E + FPP12. The actual test programs used are available from me or Bob Hassinger. 
Note that these times probably represent minimum speeds for the various configurations. 
If ycu allocate larger buffers you can probably get better results but I wanted to test the 
most difficult combinations. 

The programs are: 

1) THRUPUT comes from the TSAR package. It replaces REALTM and is much 
faster as the data is not floated but passed on to the disk with 255 AD values/ 
block. Floating is then achieved when the data is accessed (in non time critical 
environment). 

2) WRITEB by R. Phelps also achieves a more compact saving of data by re-fixing 
the data before writing to the output file. 

3) WRITBL I just wrote. Recognizing that much of the time is spent in passing a value 
to the output buffer, I wrote a routine that instead passes the output buffer address 
to FRTS. The restrictions on its use are not very severe and it works fine. I will 
put it on the DECUS tape sometime but at present you can obtain it from me or Bob. 

The results: 

Max sampling speed possible 
Routines FPP No FPP 



WRITEB is in FPP code. 

4000 is the limit for clock service in FRTS 
% = about or LT 100 



REALTM+WRITE(n) 


800 


% 


REALTM+WRITEB 


2300 


% 


RE ALTM+ WRITBL 


3000 


200 


THRUPUT+WRITE (n) 


2400 


2000 


THRUPUT+WRITEBL 


4000 


3400 



#18 14 
FROM DAN SMITH 

I've been working with FORTRAN IV on a PDP-12 without FPP. 
and am passing along som» notes about things which do not seem clear 
in DEC*s documentation , in hopes of speeding other peoples* learning 
process. Assembly-language (RALF) programming within the FORTRAN 
system is almost hopeless without full listings of 1) FRTS, and 2) 
the non-arithmetic library routines. I think DEC should either 
include these in the software support manual, or make them available 
as a reasonably-priced package separate from the rest of the FORTRAN 
source. 

I would appreciate any comments or corrections. In particular, 
I would like to know if there are any techniques suggested here which 
would not work on a system equipped with FPP* 

1 } Debugging 

On a PDP-12* a very useful technique for debugging RALF code 
is to set an E-stop at location 0004-0. These are "the low 12 bits 
of the simulated FPP program counter* With the stop set, (which 
should be done after the program has begun initiation — it is 
helpful to begin the program with a READ(4, format) DUMMY), repeatedly 
pressing CONTINUE will "single-cycle" through the RALF code* The 
memory buffer may be read as the address of the instruction being 
executed} that is, one should wait until the address has advanced 
just beyond the current instruction before examining memory or FLAC 
for its effect. One can freely use examine and deposit, and still 
have the program continue normal execution when the E-stop is removed t 
however t for reasons thai I don't understand, fill step and step exam 
should be avoided; I suspect that they destroy some internal registers 
or status information that are needed to proceed correctly after an 
E-stop. 

2) Normalisation 

It is sometimes desirable to write machine-language programs that 
generate floating quantities! for example • a data-acquisition program 
that generates a file structure that will later be read by a FORTRAN IV 
unformatted read. For this and other reasons, it is useful to know 
the floating-point format, and. in particular, how normalisation is 
handled. 

FORTRAN IV arithmetic routines assume that the operands, are 
normalised, and may produce incorrect (not just inaccurate) results if 
this 1c not the case. (For example c the floating add assumes Yhat a 
quantity must be sero if the high half of the mantissa is xero.) 

Unnormalised quantities can be generatedby ordinary FORTRAN code 
in several waysi by the use of Hollerith variables, by unformatted 
reads, or by calling RALF subroutines. Fortunately for those of us 
who like to manipulate Hollerith, ordinary data transfers (e.g. I«J) 
do not perform normal i sat icn. In fact, it is rather tricky to forc^ 
a normalisation in FORTRAN codei QfQ+Q will not do it. One should i.,ver 
attempt arithmetic on unnormalised quantities! this includes the 
formatted output routines, which £o ugly things if the quantities presented 
to them are unnormalised. (Note that nonzero integers within the 
FORTRAN system are, of course, normalised). 
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The condition for normalisation is that the mantissa M 
satisfies 1/2 .LE. M *LT. 1* This is almost, but not quite* equivalent 
to saying that the two Mghest bits must differ. There are two 
exceptions • both involving negative numbers t 60000000 is a legal 
normalised mantissa, and 40000000 is not . It is important to avoid 
creation of the quantity 40000000* It is not sufficient to dump 
an unnormalised quantity into the FLAG and do an FN0RM, because it 
turns out that FN0RM does not properly handle 40000000. 

3) Use of FLAC from 8-mode sections 

Although it is not mentioned in the RALF manual as a way of 
communicating between RALF and 8-mode sections, when running under 
FRTS, the FLAC is located at 00044 f 00045, ana 00046. Thus 8-mode 
sections can access or alter the FLAC. I believe this would be true 
when running with an FPP as well, because the APT should be saved and 
restored from the same locations! that is, I believe this technique 
isn't mentioned in the RALF manual because it is FRTS-dependent, not 
because it won't work with an FPP. Can anybody out there confirm or 
deny? 

4) Watch out for autoindexingt 

I've been burned a couple of times by forgetting that a SECT8 
section can loma anywhere— spec ix ic&lly, it can xoad into page 0. 
Thus, any SECTS section should either be checked carefully to make 
sure that no indirect references are made in locations 10-1? (and 
that includes JMPjC's, folks), or it should be forcibly prevented from 
loading into page by making it a FIELD1 section and including 
something like COMMZ #PAG50, ORG 200 just before the FIELD1 declaration. 

5) Operand locations in STARTD mode 

The formulae on p. 5-8 of the 0S-8 handbook cion't seem to 
fully specify exactly which words constitute the operand, particularly 
in STARTD mode. If Y is the operand address, as computed from the 
formulae, then in STARTF mode, the operand in all cases consists of 
words Y, Y+X, and Y+2. In STARTD mode, however, it consists of words 
Y and Y+l when the instruction is double-word direct reference or 
single-word indirect reference* but consists of words Y+l and Y+2 
when the instruction is a single-word direct reference. This scheme 
makes sense, because it permits the address part of the indirect 
address pointers to be loaded or stored by single-word direct references, 
but it is not immediately obvious from DEC's description. 

Notice also that base-page offsets are always rms2&£plied by 3, 
regardless of mode. 
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6) RALF addressing pitfalls 



Problems arise if RALF elects the single-word direct addressing 
format when the programmer does not expect it. Two likely examples i 

a) The programmer is in STARTD mode and expects the operand 
to be at Y and Y+l* Because the single-word format is 
used, it will actually be at Y*l and Y+2. 

b) The difference between the address* A, and the base page 
origin, B, is not an exact multiple of 3* In this case* 
RALF happily computes an offset of (A - B)/3 with no 
warning or error message* The effective address will oe 
at A - ( A - B mod 3), which is not what the programmer 
expects* 

For an example of . these problems* see the original coding of the 
FORTRAN IV clock routine, in which the TIME entry point references 
FLDA OVRCNT instead of FLDA# OVRCNT. 

This leads to the interesting question of just how RALF decides 
which format to use* It is more complicated than the i*anual implies. 
A working hypothesis follows t let FINS stand for any of the data 
reference instructions FADD, FDIV, FKUL, FSTA, FADDM, FLDA, FMOLM, 
and FSUBi let A be a symbolic location on the base page* 

a) Adding a # suffix (FINS#) forces the two-word format 
(as documented on p* 5-22)* 

b) Adding a * suffix (FINS' ) forces the one-word format 
(is this documented?) 

c) If a symbol A is forward referenced by an unsuffixed data 
reference instruction* then all references FINS A will 
use the two-word format* 

d) If A is not forward referenced, or is forward referenced 
only by instructions of form FINS# and FINS* (or by 8-mode 
instructions), references of form FINS A will use the 
one-word format, and will be correct only if (A - B) is 
an exact multiple of 3* 

In general, it is wise to use the # suffix unless the address 
is known with certainty to lie at an exact multiple of 3 on the 
base page* It seems particularly important to use it when using 
double-precision mode to stuff addresses, instructions, JA's, etc* 
into the middle of executable code* 

A rationale for point (c) above Is as follows • during pass 1, 
forward references must be the long form, because it is not yet known 
whether A is on the base page and the assembler must make a commitment 
so that the location counter does not become undefined* It would seem 
that backward references could still be the one-word formg however, 
during pass 2 it is difficult to distinguish forward from backward 
references without complicated symbol-table entries (since all symbols 
are defined at the start of pass Z)\ so the simplest workable solution 
is to flag the forward reference in the table and always use the long 
form* 
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It seems -to me that DEC should give high priority in their next 
RALF revision to having RALF either a) use the long form, orb) give 
an error message* or c) both* when a base~page reference is not 
divisible by 3* Any of these options is easily implemented with 
about a dozen extra words of code. Unfortunately, RALF's field 
is pretty tight right now* and finding those extra words seems 
unlikely unless some code can be moved to field 1* which is feasible 
but will take some work* 

The following kludgey patch will implement option a) above for 
users with 12K or more* Warnings it hasn't been texted extensively 
yeti 



PATCH FOR RALF V60A 



•GET DTAl HALF 



L: 






t 

-a 

W 
*? 

s 



•ODT 
6262/0140 3240 

1120/4772 

01121 /1155 6222 

01122 /1046 

01123 Z4560 * 
03041 Z0000 
ihd*A*di for t\afl*3 
23000/0067 

23001 /1061 

23002 /0070 

23003 /020e 

23004 /1 122 



/make patch level "Z" (bo won't b* 
/confused with genuine DEC patches! ) 

jms i (over3 

cif 20 /replaces tad C200 

fpp83* tad opcode /ouse up AC if entry from formt2 

jms i foutwrd /when entry is from formt2* we'll 
/jms to 23041 instead of to outwrd 



23042/7200 

23043 /1600 

23044 /7650 

23045 /5250 

23046 Z6203 

23047 /5601 

23050 /1602 

23051 /1203 

23052 /6203 
22053 /5604 
*C 

• SAVE DTAl RALF 



j no cJiM^e \L*ksk 
extmp 
formtl 
extmp2 
200 
fpps3 

cla 

tad i (extmp 
sna cla 
jmp .+3 
cif zAS 
jmp i (formtl 
tad i (extmp 2 
tad (200 
cif cdf 
jmp i (fpps3 



/over3 leaves remainder^ here 
/entry point for long form 
/over3 leaves quotient here 
/constant 

/ignore return address from jms 
/ac has garbage at this point 
/pick up remainder 
/if it's bad, 



/then return to formtl 
/with AC clear. 

/pick up quotient* fomtunately still around 
/do instruction clobbered by cif 20 
/and return to fpps3, with AC and hopefully 
/everything else just like they would have 
/been without patch 
0-7600* 12000-13777*23000 % /save more than we got! 
(PKcxrfMM, *mf**, Patch J 
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7) Driving user routines via CLOCK 

Although the manual says cryptically that a "common" use of the 
FORTRAN IV CLOCK subroutine will be in conjunction with REALTM, it 
does not explain how it can be used for anything else. 

The CLOCK subroutine contains an entry point, #CLINT, which seems 
to be intended for users. #CLINT is a two-word (STARTD mode) block, 
which initially contains zero. At any given time, #CL1NT should contain 
either zero, or the ADDR of an 8-mode subroutine. The subroutine must 
reside in field 1, is entered with AC clear and IF*DF^1 via a JMS, 
and should return the same way (i.e. it should follow the same rules 
as a subroutine for use with ONQI or ONQB). The subroutine will be 
called once per clock tick. If no clock subroutine is desired, set 
#CL1NT to zero and then CLOCK will maintain the right time and listen 
to the echmitts if desired, but will do nothing else. 

8) A bug in CLOCK 

Which brings up an interesting point. Routine IDOCLK in the 
CLOCK routine is incorrect, in that if any achmitts are enabled, 
the #CLINT routine will be called on interrupts from the schmitts as 
well as from the clock overflow. 

Since REALTM works by dropping an an address into #CLINT 
(#CLINT can only be used to service one routine at a timet needed, and 
presently under development, is an ONQB-like routine for use with 
the clock), this means that presently, if any schmitts are enabled, 
REALTM will aample and buffer ths s~te-d"s on schmitt events *»s well 
as clock ticks, which is probably a bad thing. 

The remedy is obvious i just after JMP L0P2 following D0TR16 in 
the clock routine should be inserted CLA, TAD CSTAT, SKA CLA. JMP* 
IDOCLK (to skip the call to #CLINT if the clock didn't overflow). 
This change hasn't yet been tested. 

9) More conflicting device codes 

So Hans W. Goebel think* 8 he's been had because the FPP-12 
maintenance IOT's conflict with his AF04? We've got the same problem, 
only different i our AA5? D-to-A converter has device code 655x, same 
as the FPP itself! First, the good newst we don't have an FPP and 
don't plan to get one. Next, the bad newsi FRTS talks to your FPP 
even if you don't hare one, once per interrupt. Next, the good newst 
a nop at 0040? in FRTS shuts it up. 

— Dan Smith 

Eye Research Institute 
20 Staniford St. 
Boston, Mass. 02114 
617 7^2-3140, X 260 
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Shift/8: A Program to Convert FPP to BCD Numbers 



Minicomputer systems usually do process control functions under assembly 
language programming, while the requirements imposed by the user to do ana- 
lytic computions normally forces the user to leave the realm of assembly 
language programming and use higher level languages as Focal, Basic or Fortran. 
With the help of the Floating Point Package (FPP) and its associated mathe- 
matical subroutines, it is possible to do analytic computation in assembly 
language with comparative ease. The nature of the FPP number, however, does 
not lend itself well to output. One FPP number uses 3 core locations. These 
core locations contain the binary equivalents of the exponent and mantissa t 
When outputting to peripherals, data formats are usually specified by some 
type of 7 to 8 bit serial or parallel BCD ASCII code. Therefore, all data 
must be transformed to a properly coded form if it is to be transmitted from 
mini to a peripheral. 

This subroutine provides a method of converting the 27 bit FPP 3 numbers 
to an equivalent 3 digit ASCII BCD number. All FPP numbers must be normalized 
to be 999 (base 10) before the call is made to the subroutine. Two features 
of the subroutine are that 3 word FPP number can be preserved or overwritten 
by the subroutine is completely relocatable. 

The Shift/8 operation is carried out on 3 word i?PP data arrays auto- 
indexed by octal core location 0011 and the coresponding _» digit BCD numbers 

By loading the same data location into core location 1 1 and 1 2 , the BCD num- 
bers generated by Shift/8 will overwrite the respective FP? numbers „ This 
could be utilized as a core saving feature of Shift/8. The number of data 
points on which Shift/8 is performed is specified in the location labeled 
REFC. 1 * Shift/8 is self initializing su^h that one REFC is fixed for a single 
array, N arrays may be changed by calling Shift/8 N times. Care must be 
taken in the user program to insure that core locations 11 and 12 have been 
set with the new array locations. 



*See Intro to Programming, Chapter 8, p8-1, 8-41 

2 A case in point is the output software handler need for the PDM-70 as 
indicated in the article, "Interfacing the FDP-8/L to the Laboratory Using 
A Programmable Data Mover? Decuscope, Volume 14, Number 3 

3 DEC-08-NFPEA-A-PB (1972) 

This counter should actually reside in page and be loaded with the 
number of variables before the routine is called, 

CLE&REJF 28 Aug 75, INFO OFC, ECOM 
JEFFfiRY A. SLUSHER, INFO Ofcr, NVL 
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7767 




/SEE FOOTNOTE #4 


ASCI I 


531 










CC 


0532 










OJT 


0514 










CWTRL 


0515 










PJPUT 


0512 










K12 


0526 










*ASK1 


503 










KASK2 
YASK3 

m^s:<4 

¥A5r<5 
MASK 6 
MASK7 

W-VjR 


0504 
0505 
506 
50 7 
0510 
O 5 U 
OS 13 
0403 




PMTr* 

RrFC 

HOT 

SH I F T 

STORF 

TA°LF 

TF>?pi 


04/iO 
0533 
04P5 
04^tf 

3 5P7 
0516 
533, 
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FORLIB 'SYNC EXTENSION FOR DK8-E CLOCK 

Ian M. Templeton, National Research Council 
of Canada, Ottawa, Canada K1A OR6 
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The standard CALL SYNC (l,N) returns N=l if Schmitt trigger I has 

fired since the last call (1=1 % 2 or 3)- A minor modification allows 

1=1* to return N=l if the clock has overflowed since the last call, and 

thus provides for simple clock synchronisation. One more flag location 

is provided and precleared on a call to CLOCK, and a U-word patch is 

inserted in pl^ce of some redundant KW12-A instructions. The changes 

may be made with EPIC, but the precise locations to be changed must 

be determined by the user. The cnly occurrence of CLAB (6133) provides 

a useful pointer. In the latest version of FORLIB, CLAB occurs at location 

337 of block K, and the modifications are made at N( 3^1-2), »( 361-75) 

and N+l(21 & 35)- 3&e required changes are listed below. N.B. An 

earlier version of FORLIB has addresses in SYNC differing by 1. If N(3**l) 

contains 1230 instead of 1231 all the commands marked * should be reduced 

by 1. 
J .P EPIC 



*FGFLIB.PL</!S 
p 

S*6133*7777 

0107 033? 

6133 / 

0*337 

6133 / 

7200 / 

1231 /3227 * 

0364 /7000 

0*361 

1366 /1365 

/0364 

/1375 

/3204 * 

/I 604 * 

/3365 

/3 604 * 

/6203 

/5712 * 

/7510 PATCH, 

/1324 * 

/0363 

Z5353 * 



7110 
1365 
7430 
7041 
0201 
137 5 
3204 
1604 
3365 
3604 
6203 
5712 

P*110 

0*20 
1223 

0364 
7440 
0*34 
0017 
0377 
E 



/ 

/5324 
/ 

/ 
Z0007 



ON* 

P17* 
P7*- 



CLAB /USEFIT SEAPCH POINTEP 

CLA 

DCA STFLG+3 /CLEAPS 4TH FLAG LOCM 

NOP 

TAD FCNVD /1*2*3 OP 4 REQUESTED 

AND P7 /MASK TO BE SUPE 

TAD KSTFLG+1/FLAG POINTEP 

DCA SETCLK /TEMP STOPE 

TADS SETCLK /GET FLAG 

DCA FCNVD /PETUPN OR 1 

DCAZ SETCLK /CLEAP FLAG 

CIF CDF 

JMPX DOSYNC /PETUPN 

SPA ./BIT £ 

TAD PATCH 

AND Pi7 

JMP ON 



TAD ISVBIT 
JMP PATCH 
SZA 

17 
7 



1 IF CLOCK OFLO 
/SET BIT 8 IF CLOCK OFLO 
/MASK AC 8-11 



*tC 
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fr|*iTQ )p ^&^[r \n 



T-«ESP datcm^ T) THE ^^^fC jWE^L^YS CJPECT - ai»c- ^)Tfr ? >j T^'E 
DfL-lT^L ^OFTI-apE >l€>5 F3= i T~<'E pOP-^» <=E^ ! *EMCE *> \ » J-M 7A. T-'-Y ^L*5) 
•ADD a ^[ i-MI FIC~\ ; T £MHA\JCE>*:EvT» T &€^ ^Y'fES s«ip-» f TT^P t-s r *^ 

EaIHAMCE^EMT T3 j^F. jS/3 SI i ME ! -~LETTEP >j ) ? s, Pi 1, -z\\T FT r^lL? ) \» 

THE ~ric- FI <ED IS THE "fV EP^JP- T-* i S PATCH P~hV,*F\'T^ y-?w c/^t^^ 

FP3* q^ac-: [ -ji- .,MrF\j THIS 3CC 8 'JPF.S ~ Y PE-^l- appi >][- THE 17^"*-:* PAJ.-F. THE 

EMHA>iOE v lEMT IS T3 ^lL)'.': FILE L3 3K-L ip S >. [TH)ny f=?p)^q. if THE '.))-(-"P 

FAIL"* THE EMD- 3F-FILE PIT IS Q ET <^3 THAT A "IF FMO #>i 1-3T) «<<<" OA>j 

TEST THE ^ S «CCES^ 3F THE 3PEPATI)\5 a go ALL3'*- THE PQ)t-ca< t) C3NlTI\iHE. 



• I'ET ^YS:«ASIC»FF 

• 30T 

1^310/i&5l^ S77.6 < ]v r p f /patch .. !•&<; ?QP)x C*LL> 

i/il7^/>f<KX ">5^4 c<PATC-*# "-'ATCH «►. AOOPFSS )F -'^f F)=? p<*tC-0 

p//!/<.<>(/ =■-•-.-• (GIF 13 •• ST^FT RY C a LLI >ltr THE ncp) 

PS/^/'"'^ -ft 4 7 7 ( j V ;^ I 5 » S R ) 

135^*/*X<* 11 C=^^3 J T) 

135A7/<X* r < -A556 C J*S I pisuap . „ ^fr^T)^c pai-F ]7A^^) 

n55C!/*<<* 71/j«£ (SET AC = -2>) 

i ^c c « / ^ >/ v' ^ •ice /'-rA.r. r v~.;."Vyi r«TT tj~ ner> >"> ~> r~> ~ -rv.ZAf r* -m » <» c r\ cr- — \ 

f ■>_-_>•' "». ~. ■». -» t ' _? J *-t — i ' t "\ r -»•_» » »»» \^r_i : • i. - . ,-. ■* jz- •. . i-»—»: •_, — -.-»-,. r _ -. — , 

13S5^/*<X< 7*5^ CSvA CLA .. i- ac jt L33K-'!P 3P EMTE=??> 

1355^/<'< v ss^l CL03*-*»P» SO SET EOF PIT* MO EPP 3P > 

j ISS**/****; ^SiA CENTER* A HAPQ EPP3P* ° if T MO CPASH) 

11555/*<<* -43«S (XF^*)* F\i0*1 ... AOOPE^S 3F MSP C30E APfc) 



. qA *=:YS: » ASIC »FF 

• CrET sy«:;PASIC»SF 

• DOT 

l^^lS/1^^7 &oo-\ (-^E». EPP CALL-1) 

tC 

FROM: Stuart Dole 
.sa ^vs:hasic-sf 1386 HSE 



Univ. of Calif. 

School of Medicine 

San Francisco, Calif. 94122 




#18 24 



SOFTWARE PERFORMANCE REPORT 



SPR#. 
Pag*. 



of. 



Norn* 



U. van Zee (That's 'J' as in 'Jim') 



Company 

Pept. of Chemistry BG-10 



Address 

University of Washington 



Seattle. Washington 



Phone 



98195 



(2Cn) ^^-2576 



Date sent 



Computer 

PDP-12^ etc 



System program & version 
PAL.8-V10 



System device 
RK05 



26 August 1976 



j Memory 

8k 



Attachments 



f") terminal 
printout 



Monitor & version 

QS/S-V^C 



Software Specialist 



Office 



Cost Center 



Report type 
(3 Logic/coding error 
£j Documentation error 
Suggestion 
£j Inquiry 



Other hardware 

LINCtapes 



Document 
OS/8 Hanobook 



□ object 
tape 



f~] source 
tape 



Page 



Q listing 



|SQ example 



New version*qf PAL8 has vastly reduced symbol table - hence can 



NOT ASSEMBLE MANY PR08RAMS WHICH CAN BE ASSEMBLED WITH V9* HANDBOOK 



states QQ2 symbols/*1K (Fields 1 akp above) with 89J on a 8k system. 



I OBTAINED 8QU WtTH V? r BUT ONLY G^6(lll) WITH V10. THE TEST PROGRAM 
CONStSTEO OF A FILE CONTAINING TAGS: SYM0J00, ... SYMXXX, ETC. THE 



NUMBERS QUOTED ABOVE WERE THE NUMBERS PRINTED AFTER THE 'SE' PRROR 



MESSAGE. HENCE 1 MIGHT BE OFF BY 1 DEPENDING UPON WHETCR THE ERROR 



REFERIS TO THE PREVIOUS SYMBOL OR THE ONE THAT OVERFLOWS. 



Have discovered that V10 will automatically use additional core 



(SO DON'T NEED TO SPECIFY /K ) - THAT'S NICE BUT HOW ABOUT ALL US USERS 

with 8k systems?? Will you continue to support both versions? 



Suggestion for a minor improvement to both versions: Add a file 



COUNT ERROR MESSAGE SO THAT AN INAPVERTANT «$' IN A FILE BEFORE THE 



LAST ONE WON'T LEAP TO INCORRECT ASSEM8LT WITH NO INDICATION OF AN 



ERROrt (ASSUMING THAT LATER FILES ARE OVERLAYS, ETC. WHICH CONTAIN NO 



FORWARD REFERENCED SYMBOLS - A COMMON SITUATION). MY IDEA IS JUST TO 



COUNT THE FILES FROM THE CD INPUT, DECREMENT AT EACH EOF AND ERROR OUT 



FOR SOFTWARE SPECIALIST USE ONLY 



DATE RECD 



DATE ANS'D 



TO S.C. 



TO CUSTOMER 



FOR SOFTWARE COMMUNICATIONS USE ONLY 



DATE RECD 



DATE ANS'D 



TO MAiNTAlNER 



TO SPECIALIST 



IF $=0 



DEC 7^360)- 1044B-R373 



UARSO FORM NO. 41-307-34 




SOFTWARE 

PERFORMANCE 

REPORT 
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FIELD #: 


[SPR #: 


- - . "-"""-* 


* -- -~ 




1 
FOR DEC USE ONLY 







28776 



Page. 



of 



SYSTEM PROGRAM ANO VERSION {OR DOCUMENT) 

FORTRAN IV 3.05 



MONITOR ANO VERSION 



OS/8 V3C 



DATE 

76-07-13 



DEC OFFICE 



NAME: 
FIRM: 



ADDRESS 



Lars Palmer 

abhXssle 

Fade 

431 20 MOLNDAL 1 

SWEDEN 



ZIP 



SUBMITTED BY: 



PHONE: 



UsT 



REPORT TYPE 

09 LOGIC/COOING ERROR 

□ DOCUMENTATION ERROR 

□ SUGGESTION 
Q INQUIRY 

D FOR YOUR INFORMATION 



PRIORITY 

D COW 

CS STANDARD 

CD HIGH 



T ATTACHMENTS 



CAN THE PROBLEM BE REPRODUCED AT WILL? 
CS YES □ NO 



CPU TYPE 
8E 



SERIAL. NO. 
512 



SYSTEM DEVICE 
RK8E 



MEMORY SIZE 
32 



DISTRIBUTION MEDIUM 



Compiler - Assembler does. not detect a memory overflow in a Dimension statement. 
See enclosure. 



CORE 
22K CORE ' 

EX TEMP. FT-TSF/TS OS/8 FORTRAN IV 



0002 




0003 




0004 




0005 


10 


0006 


160 


0007 





D I HENS I ON ft < 4080 > .. B < 4£i0O > , C ( 4080 > 

DRTh h E-- C.-'I2O00 + 0/ 

DO 10 1=1. 10 

W P I T E < ■ 1 8 .'•■ I 

FORMATS I6> 

END 



JUL 13 1976 



NO ERRORS 

21 SYMBOLS, NO ft6S REFS 



# 


C 00000 


#BftS 


:E 


88822 


tEXIT : 


*! 80808 


#G0BftK 


00857 


#»30001 


0640© 


#00082 


06404 


#LBL 


06 3' 70 


#LIT 


00075 


BMftIN 


S 57820 


#NE 


*■ 


■'. 00008 


#REND0 I 


K 80000 


#RET 


00015 


#RSV0 


V 00808 


#ST 




06270 


#TMP 


00064 


#wpito : 


K 00800 


#XR 


OOO02 


#18 




06406 


#18© 


06421 


H 


00130 


B 


27470 


c 




57020 


I 


00061 







INPUT ERROR 



"v-v, •«;>,. ::■«...„ 
DO NOT «—. 


c Tf^W " •.»*»••»— v »vw. .,. 


SOFTWARE 


■vs. •..,. -r. -;..\-.„ : ■> •-■ . v»v.-.. .- 

COMMUNICATIONS USE ONLY 


•^*v .- ™ -. ^\ r \^ -. . '"T 




DATE RECEIVED 


BACK FROM MAINTAINS* 


LOQQEO ON 


TO MAINTAINER 


OATE CLOSED 


LOGGED OFF 



SOFTWARE COMMUNICATIONS 



DEC 7 (360) 1044C n«74 



